TuLiP : reshaping trust management

ing away from the low level implementation problems (like network failures), thefirst threat above can result from two different situations: (a) the User Client application maybe compromised and (b) the Mode Register becomes compromised and returns the wrongmodes for the credential atoms. The situation in which the User Client application is com-promised (a) is less interesting here, as it implies that the adversary probably already hasaccess to the user’s machine and therefore the user’s TuLiP account. In this case the ad-versary can masquerade as the user, and Tulip cannot prevent any malicious actions of theattacker. Acquiring a compromised version of the User Client application by the user can beavoided by performing an integrity check (see for example GnuPG [51]) on the applicationbinaries. An attack on the Mode Register (b) is more subtle and therefore more interesting.Recall that the User Client application receives from the Mode Register the modes of thecredential atoms for each newly issued credential. Because in Standard TuLiP the modesassigned to the credential atoms in a credential determine the depositary of this credential,by returning invalid modes from a compromised mode register, the adversary influences thestorage location for newly issued credentials. The following example demonstrates what mayhappen when the adversary can manipulate the modes. Example 5.3 Assume that eStore wants to issue a credential allowing all the students fromeach accredited university to receive a discount. Then let us assume that the valid (i.e. non-compromised) mode values for the credential atoms discount, accredited, and student are:mode(discount) = ii = (In, In), mode(accredited) = io = (In,Out), and mode(student) =oi = (Out , In). In this configuration the discount credential would be stored by the eStore(because eStore is the issuer), the accredited credentials would be stored by the accreditationboard (accBoard in our case), and each student would store her student credential. If theMode Register is compromised, the adversary may freely change the modes of the credentialatoms. Assume that the modes returned by the compromised mode register are as follows:mode(discount) = ii = (In, In), mode(accredited) = oi = (Out , In), and mode(student) =oi = (Out , In). What is different in this configuration is that now each accredited credentialis expected to be stored by the accredited university. Summarising, the credential issued andstored by the eStore has the following form: C1 : discount_ii(eStore-pub-key, X) ←−student_oi(Y,X), accredited_oi(accBoard-pub-key, Y ). This credential is traceable w.r.t. the mode values returned by the compromised moderegister, but is not traceable w.r.t. the actual mode values stored in the original mode register(i.e. mode(discount) = ii, mode(accredited) = io, and mode(student) = oi). Now assumethat alice, who is a student of the University of Twente (ut) issues query: 112 Chapter 5. Trust Management in P2P systems using Standard TuLiP Q :←− discount_ii(eStore-pub-key, alice-pub-key). The University of Twente is an accredited university. Because in the proper mode assign-ment, mode(accredited) = io = (In,Out), the accreditation board (accBoard) stores thecredential: C2 : accredited_io(accBoard-pub-key, ut-pub-key).Now, when query Q is received by the LIAR engine, LIAR will fetch credential C1(which is not traceable w.r.t. to the original mode assignment) and LIAR will search forthe accredited credential at the credential server corresponding to the University of Twenterather than at the server of the accreditation board accBoard. This is because the mode of theaccredited credential atom has been changed from (In,Out) to (Out , In). Beacuse ut doesnot store credential C2 (it is stored by accBoard), LIAR will return negative answer to thequery. It means that alice will not receive the discount she is eligible for. Example 5.3 shows that by manipulating the modes in a compromised mode register theadversary can disable some services available to the user. This can be regarded as a subtleversion of the deny-of-service attack. An additional observation from Example 5.3 is that thecompromised mode register can influence only the newly issued credentials. In Example 5.3,if the right version of credential C1 was already stored at the credential server of eStore thenthe answer to query Q would be positive and alice would receive the discount as expected.In Example 5.3, a user is not given authorisation she has rights to. A much worse situationwould be if a user who is not authorised to perform an action on a resource actually receivesthe authorisation. For this to happen it is not sufficient to break the mode register. Evenwhen the Mode Register is broken, this has only influence on the newly issued credentials.It means that, in order to gain unauthorised access to a resource or a service, one has to beable not only to have control over where the credential get stored and have access to the rightcredential server, but also have to be able to issue new credentials on behalf of another user.This can happen if the public identifier of a user becomes compromised, which means thatthe adversary has full control over the user’s account.An interesting situation occurs when the mode register is not compromised (i.e. the moderegister returns valid mode values), but the adversary has full control over the user’s account. Example 5.4 Assume the following state: eStore:(1) discount_ii(eStore, X) ←− accredited_io(accBoard, Y ), student_ii(Y,X).accBoard:(2) accredited_io(accBoard, ut).ut:(3) student_ii(ut, alice). In this scenario each credential is stored by the issuer. As a consequence, even when hav-ing full control over the account of another user, the adversary cannot receive authorisationwhich was not already given to the user. In our example, if credential (3) does not exist, theadversary will not have discount at the eStore despite having full control over alice’s account. Section 5.6. Related Work113 Example 5.4 shows, that by careful selection of the modes the bad consequences of an attackcan be limited. Evaluating a query When evaluating a query, the use of the Mode Register is not re-quired. Unless other system components are also compromised, the system remains con-sistent as long as no new credentials are added to the system even if the Mode Register isbroken. Still, the use of the mode register during the query evaluation can be considered inorder to dynamically validate the modes occurring in a credential.Assuming that the mode register is not being used during the query evaluation, the ad-versary may target the following system components: the User Client, the LIAR engine, andthe Credential Servers.If the adversary manages to make the user work with a compromised User Client appli-cation, the adversary can quickly gain full access to the user’s machine and therefore takefull control over the user’s TuLiP account. As before, this attack can be avoided by perform-ing an integrity check on the on the application binaries and by making sure that the user’scomputer is free of malicious code.The LIAR engine and user’s credential server might be run on the user’s machine orcan be considered part of the underlying infrastructure. In the first case, the integrity of theLIAR engine (resp. a credential server) must be protected in the same way as the integrityof the User Client application. A compromised LIAR engine (resp. credential server) leadsto the same problems as a compromised User Client application: a compromised user publicidentifier and the full control of the user’s account by the adversary.In the case when the LIAR engine and the credential servers are part of the underlyinginfrastructure, the integrity of the system directly depends on the security of the underlyinginfrastructure. In Section 5.3.3 we show how Distributed Hash Tables (DHT)[85] can beused in Standard TuLiP to provide the mapping between a user’s public identifier and thenetwork address of the credential server corresponding to this user. In this approach thecredential server is part of the infrastructure, and the user does not have to run an instanceof a credential server on her machine. The same approach can be used for the deploymentof a LIAR engine. In this approach, besides running an instance of a credential server, eachDHT node also runs an instance of the LIAR engine. In this case the LIAR engine used toevaluate a query may be determined by the identifier of the query issuer or the issuer of thefirst credential atom in the query (other approaches are also possible). As a consequence, theuser does not know which LIAR engine is used to evaluate the query. This makes access tothe LIAR engine more difficult also to the adversary.